1. Field of the Invention
The present invention relates generally to methods and apparatuses for tracking multiple payment resources and charging transactions to multiple payment resources according to a flexible rating engine in an on line transaction processing system
More specifically, the invention relates in certain embodiments to methods and apparatuses for debiting and crediting existing payment resources or creating new payment resources using an object oriented scheme. Data relating to payment resources is transferred to and from an object server using a container object. The object server interacts with both a transient storage that is organized according to an object-oriented scheme and a persistent storage that is organized according to a relational database management scheme. The relational database in persistent storage is designed by the object server. This includes defining the tables of the relational database as well as the various columns. The object server then stores and retrieves data from the various tables defined in persistent storage according to a hierarchical tree that maps data encapsulated within objects to table locations in the relational database found in persistent storage.
When an event occurs that requires payment from a payment source, or when authorization is sought for an event that will require payment from a payment source, a rating engine analyzes a number of rates that are available, resources that are available, and available credit limits to create a rate stack that determines authorization and charging for a transaction.
2. Description of the Related Art
Billing has become increasingly complex in the field of on line transaction processing. In particular, convergent billing, where multiple services are billed to a customer on a single bill has become an important goal of on line transaction processing systems. In such systems, multiple sources of payment may be used to pay for services. For example, a phone company may provide both long distance phone service and internet access and may also handle billing for a certain on line services accessed by a customer. As the customer accesses one service, it may be desired to give the customer free time on one of the other services as an incentive to use both services. Additionally, it may be desired to give the customer some other sort of incentive such as frequent flier miles whenever the customer accesses a certain service. Payment for a given service may then be made from any one of these multiple resources, which must be tracked.
The problem becomes more complex when an authorization event or a payment event occurs. Different payment rates from different sources must be analyzed to determine the rate to be applied. In the case of an authorization, different credit limits applying to different sources must be checked.
One of the most important requirements of such a transaction processing system is the need to add payment resources and rate schemes without extensive reprogramming. Traditional payment systems have not been successful in meeting this requirement. The need for fast, optimized searching of a very large database has militated in favor of relational data base designs for the storage of customer, payment source, and rate information. Relational databases are built from a set of tables that contain related columns. The tables are indexed in an efficient manner by the relational database so that searches may be performed in an optimal manner. While organizing information into a complex related set of tables helps speed searching, a thorough knowledge of the tables is required to specify data that is to be retrieved or to specify where data is to be stored. Creating new data and creating new types of data such as new payment resources generally requires modifying the design of the tables to accommodate the new data and often requires extensive rewriting of existing the system program code. This means that a high level of expertise and familiarity with the database design is required to add payment resources.
Another problem in many relational database management systems (RDBMS's) is that columns in tables that contain no information or are not used nevertheless take up space in memory. Thus, when new payment resources are created, a large amount of memory may be allocated for tracking the payment source for every customer. Old payment resources that are no longer used also may continue to take up storage space until the database is restructured to remove them.
A standard relational query language, Structured Query Language (SQL) is used to query most popular relational databases. SQL requires that the person who specifies a query know what tables and columns contain the information that is to be compared against the query. For example, in order to look for all customers in a city, the user must know both the name of the table that contains city information and also the name of the column in that table that contains the city information. It is also necessary that the user know the tables that should be joined to accomplish the search and how to join those tables. Likewise, in order to store information in the proper column of the proper table, the user must know the name of the table and column in which the information should be stored.
In contrast, it is easier to query, modify and write information to object-oriented databases. Instead of specifying a table and column for storing or retrieving information, related data is encapsulated in an object. The object may be read into memory and all encapsulated data may be readily accessed. Searching, however, is not as efficient as relational database searching. It would be desirable if an object oriented database could be used to add payment resources and rates and to retrieve information into a transient memory, and if a relational database could be used for persistent storage of data.
In view of the foregoing, there is a need for methods and apparatuses for defining payment resources using an object-oriented database associated with a transient memory and creating a relational data base in persistent memory that stores payment source information. It would also be useful if an efficient system for charging payments at different rates could be developed.